A 



Please type a plus sign { + ) inside this t 



PTO/SB/05 (1/98) „ 
Approved for use through 9/30/00, 0MB 0651-0032 £ 
Patent and Trademark Office; U.S. DEPARTMENT OF COMMERCE ^ 



UTILITY 
PATENT APPLICATION 
TRANSMITTAL 

(Only for new nonprovisional applications under 37 CFR 1.53(b)l 


Attorney Docket No. 


00AB025 


First Inventor or Application Identifier FranciSCO P. Maturana 


Title 


GLOBAL RESOURCE LOCATOR FOR AUTONOMOUS COOPERATIV 


Express Mail Label No. | EK927915228US 



Assistant Commissioner for Patents 
ADDRESS TO: Box Patent Application 
Washington. P.O. 20231 



Specification [Total Pages P^^j I 
(preferred arrangement set forth below) I ' 

- Descriptive title of the invention 

- Cross References to Related Applications 

- Statement Regarding Fed Sponsored R&D 

- Reference to Microfiche Appendix 

- Background of the Invention 

- Brief Sunnmary of the Invention 

- Brief Description of the Drawings (if filed) 

- Detailed Description 

- Clatm(s) 

- Abstract of the Disclosure 



□ 



IVIicrofiche Computer Program (Appendix) 



Nucleotide and/or Amino Acid Sequence Submission 

(if applicable, all necessary) 

a. I [ Computer readable Copy 

b. Paper Copy (identical to computer copy) 

c. Statement Verifying identity of above 



3 Drawing(s) (35 USC 1 



4. Oath or Declaration 



[Total Sheets | 3 | 
[Total Pages | 2 | ' 
a. I xl Newly executed (original or copy) 

b. 



(Note Box 5 below] 

□ DELETION OF INVENTOR(S) 
Signed btatement attached deleting 
inventor(s) named in prior application, 
see 37 CFR 1 .63(d)(2) and 1.33(b). 

□ Incorporation By Reference (useable if Box 4b is checked 
The entire disclosure of the prior application from 
which a copy of the oath or declaration is supplied 
under Box 4b, is considered as being part of the 
disclosure of the accompanying application and i 
hereby incorporated by reference herein. 



ACCOMPANYiNG APPLICATION PARTS 



Assignment Papers (cover sheet & documents) 

37 CFR 3.73(b) Statement | | Power of Attorney 
(where there is an assignee) 
English Translation Document (if applicable) 



a 
□ 
□ 

I I Preliminary Amendment 

□ 

□ 
□ 



*Small Entity p. Statement filed in prior applicatioi 
Statement(s) |_J Status still proper and desired 



7. If a CONTINUING APPLICATION, ctieck appropriate box and supply the requisite inform, 
I [ Continuation Q Divisional Continuation-in-part (CIP) of prior ap 

Prior application information: Exanniner: Group/Art Unit: 



18. CORRESPONDENCE ADDRESS 



Customer Number or Bar Code Li 



fxl Correspondence address below 



• (Insert Customer No. c 



h bar code label j 



John J. Horn 



Patent Dept. 704P, 8th Floor, T-29 



Rockwell Technologies, LLC 



1 201 S. Second Street 



ZIP CODE 53204-2496 



COUNTRY USA 



TELEPHONE (414)382-3960 I FAX (414)382-3900 



Name (Pnnt/Tvpe) 


Williap, R, Walbrun | Registration No. (Attomey/Agenti 


37,464 


Signature 


-^^^=^1..--^^^ — 1 Date 





or Patents, Washington, DC 20231. 



EXPRESS MAIL NO. EK927915228U S 

Docket No. 00AB025 
Ref.No. 110003.97001 



PATENT APPLICATION FOR 



GLOBAL RESOURCE LOCATOR FOR 
AUTONOMOUS COOPERATIVE CONTROL SYSTEMS 



By 

Francisco P. Maturana 
Sivaram Balasubramanian 



Express Mail Mailing Label Number #EK92791 5228US 
Date of Deposit July 24. 2000 



Pursuant to 37 C.F.R. § 1 .1 0, 1 certify that I am personally 
depositing this paper or fee with the "Express Mail Post Office 
to Addressee" service of the United States Postal Service on 
the above date in a sealed envelope (a) having the above- 
numbered Express Mail label and sufficient postage affixed, 
and (b) addressed to: BOX PATENT APPLICATION, 
Commissioner of Patents and Trademarks, Washington, DC 
20231. 



Date: July 24, 2000 

1 




1 



GLOBAL RESOURCE LOCATOR FOR 
AUTONOMOUS COOPERATIVE CONTROL SYSTEMS 



CROSS-REFERENCE TO RELATED APPLICATIONS 

5 STATEMENT REGARDING FEDERALLY 

SPONSORED RESEARCH OR DEVELOPMENT 

BACKGROUND OF THE INVENTION 
The present invention relates to industrial control systems and the like and in 
10 particular to an industrial control system comprised of many distributed controllers 

dividing job tasks among themselves using "market model" based bids and counter bids. 

In a centralized model for industrial control, a single central controller (being a 
specialized computer) coordinates all aspects of the controlled process. Input signals 
representing values from sensors on the controlled process are communicated to the 
15 central controller which executes a control program to develop output signals which are 
communicated to actuators on the controlled process. 

The centralized model is conceptually simple and requires programming only a 
single device. Nevertheless, the centralized model has some disadvantages. Control 
systems using this model are particularly vulnerable to failure of the single central 
20 controller. Further, communication of all I/O signals to a central location and executing 
the control program on a single computer, particularly for large control systems, can place 
undue burdens on processing resources and communication bandwidth. 

In the distributed model for industrial control, the control program is executed by 
a number of spatially separate controllers intercommunicating only as needed on a 
25 common network. By placing these controllers near relevant I/O points, the 

communication of large amounts of I/O data is diminished. Having multiple control 
devices can also reduce the susceptibility of the control system to failure of any one 
device. 

One difficulty with distributed control is that of developing the multiple control 
30 programs to dividing the control tasks among the various distributed controllers and 
coordinating their actions. One promising method of both dividing the control task 
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among the controllers and coordinating their actions borrows from a market model of the 
economy in which many different autonomous individuals organize themselves (through 
bidding and counter bidding) to produce complex products or services without central 
control. In such autonomous cooperative systems (ACS), a job description is presented to 
5 a large number of autonomous cooperative units (ACUs), which, based on knowledge of 
their own capabilities and limitations, bid on portions of the job and coxinter bid in 
response to requests for bids. Control programs are simply developed and the potential 
exists for control programs to be quickly changed as new circumstances develop. 
Examples of this would be if it is desired to produce a new product or if ACUs (and 

10 associated equipment) are introduced or removed from the system. A description of some 
such of autonomous confrol systems are described in co-pending patents. 

For an autonomous cooperative system to produce an optimized outcome, it is 
desirable that many different of divisions of the job among the ACUs be explored and 
thus that a large number of bids be collected from many different ACUs. This is done by 

15 allowing each ACU to make multiple simultaneous requests for bids from other ACUs. It 
follows that a single ACUs may receive multiple requests for bids from multiple other 
ACUs each of which must be considered in a separate "context" and each of which may 
mature into a different completed bid. 

The bidding process for each context requires a large number of bidding messages 

20 be transmitted over the network 16. Such messages generally include "bid requests" and 
replies to bid requests including "bid success", "bid failure" and "counter bid" messages. 
The numbers of messages increases geometrically with the number of ACUs involved and 
these messages can easily overtax even high-speed communication networks thus 
delaying the determination of a control solution. This delay limits the usefiilness of an 

25 ACS in responding quickly to changing control situations and effectively Umits the size 
of control problems that may be advantageously handled by the ACS. 

What is needed is a way to realize a freely scalable ACS system that may rapidly 
determine an optimized confrol solution that may be implemented with existing hardware 
having network bandwidth and processing limitations. 

3 0 BRIEF SUMMARY OF THE INVENTION 

The present invention provides an ACS significantly reducing the number of bid 
messages needed to provide a solution, and thus requiring less network bandwidth and 
ACU processing power. The reduced number of bid messages is the result of two 
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techniques. The first technique is the creation of a registry that directs a given ACU 
wanting to request a bid to other likely ACUs for receiving that bid. Bid messages sent to 
ACUs having a low likeUhood of successfully responding are thus reduced. 

In the preferred embodiment, at the time the ACUs are initialized, each ACU 
5 transmits its capabiUties (such as might be provided to a requesting ACU) one time only 
to the central registry rather than many times to each requesting ACU. The central 
registry, by providing a single source overview of the capabilities of other ACUs, can 
significantly shorten the time required for a given ACU to find other ACUs of particular 
capabilities. The registry thus acts like a central clearinghouse or central market in 

10 simplifying transactions. 

The second technique of the present invention employs a cache-like structure in 
each ACU into which portions of the registry may be downloaded. Unhke a conventional 
computer cache, the cache holds potential relationships between the given ACU and its 
bidding partners. This technique reduces network traffic by allowing the ACUs, in many 

15 cases, to accurately identify other relevant ACUs without referring directly to the registry 
eliminating the registry directed messages. When the necessary data is not found at the 
cache, a request may be made of the registry and the registry may use this to further refine 
its prediction of which data should go into the cache. 

Specifically then, the present invention provides a method of coordinating a 

20 plurality of autonomous cooperative units implemented in computers intercommunicating 
on electronic network and operating to divide a predefined job among ACUs by a bidding 
process including bids communicating among the ACUs. The method provides that for 
each ACU, a subset of all ACUs of the system are identified as potential bid request 
receivers. This subset may initially be based on the capabilities of the ACUs as being 

25 compatible with capabilities of other ACUs. This subset is stored as a list of potential bid 
receivers in the computer implementing the ACU. When the ACU receives a description 
of the job, it preferentially communicates requests for bids related to the description of 
the job fi-om the given ACU only to other ACUs on the list of potential bid request 
receivers. 

30 It is thus one object of the invention to provide a systematic exploration of 

solution space as regards possible combinations of ACUs to compete bids for a given job. 
The list is selected to indicate likely candidates for the bidding process thus greatly 
simpUfying the number of ACUs that need to communicate and reducing total 
communications. 
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The method may include storing at a designated computer a relation table relating 
each ACU to capabilities of potential bid request receivers for that ACU. The designated 
computer may collect from each ACU on the network, that ACU's capabilities and may 
reply to requests from these ACUs, looking for potential bid request receivers, with those 
5 ACUs having capabilities matching the capabihties of potential bid request receivers of 
the given ACU in the relation table. 

Thus it is another object of the invention to centralize communication of 
capabilities among ACUs and thus to ehminate many separate transactions between 
ACUs that would redundantly communicate these capabilities between ACUs. 
10 Each ACU may transmit its capabihties to the designated computer upon 

initialization of the ACU. 

Thus it is another object of the invention to automatically generate the relation 
table at the initialization thus eliminating it as a task necessary to the programmer and 
reducing the burden of this process during run time. 
1 5 The designated computer may also implement at least one of the ACUs. 

Thus it is another object of the invention to provide the benefit of the designated 
computer without departing from the distributed model of the autonomous cooperative 
system. 

The process of preferentially communicating requests for bids with other ACUs 
20 based on this list may include the steps of reviewing the Ust of potential bid request 
receivers for ACUs likely to complete a portion of the job based on information about 
likelihoods incorporated into the list. When there are no likely ACUs, the method may 
include communicating with the designated computer to receive a new cluster of ACUs to 
update the hst of potential bid request receivers and then preferentially communicating 
25 with an ACU on the updated list. 

Thus it is another object of the invention to provide an efficient communication 
between the more comprehensive list of potential bid request receivers contained at the 
designated computer and the smaller but more efficient list contained at the device 
implementing the ACU. This updating process potentially allows each ACU to have 
30 ultimately the fiill range of ACUs in front of it but allows internal and efficient access to 
the most likely ACUs within that range. 

When the ACUs in the list are considered unlikely to successfully complete a 
portion of the project because of their historical responses, the designated computer 
provides a new hst of ACUs that are simply different from those previously provided. 
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Where the Hkehhood is based on the lack of ACUs of a given capabiHty (for example, as 
a result of an unexpected job) the designated computer alters relation list to provide 
ACUs under the criterion of having the needed capability. 

Thus it is another object of the invention to exploit whatever information is 
available to focus the bidding process on the most likely bidding candidates. 

The foregoing and other objects and advantages of the invention will appear from 
the following description. In this description, reference is made to the accompanying 
drawings, which form a part hereof, and in which there is shown by way of illustration, a 
preferred embodiment of the invention. Such embodiment and its particular objects and 
advantages do not define the scope of the invention, however, and reference must be 
made therefore to the claims for interpreting the scope of the invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a simphfied perspective view of a manufacturing process including a 
number of separate machines intercommunicating via distributed computers connected 
over a network such as may be used with the present invention; 

Fig. 2 is a block diagram of one of the computers of Fig. 1 showing a standard 
architecture for control including a processor, a memory holding data and programs 
executed by the processor, a network card providing an interface to the network of Fig. 1 
and I/O circuits for communicating with the machines of Fig. 1; 

Fig. 3 is a functional diagram of the program and data structures stored in the 
memory of Fig. 2 including programs implementing autonomous cooperative units, 
subcontract bid managers associated with each autonomous cooperative unit, a cache-type 
local resource locator and optionally a global resource locator, the latter which may be 
implemented in one but not all of the computers; 

Fig. 4 is a hierarchical diagram showing organization and communications 
between the programs and data structures of Fig. 3 as implemented in different computers 
of Fig. 1; 

Fig. 5 is a block diagram showing the operation of an autonomous cooperative 
unit its subcontract bid manager, the local resource locator and global resource locator of 
Fig. 4 when a new autonomous control unit is initialized such as creates lists of potential 
bid request receivers in the local resource locator; 

Fig. 6 is an expanded fragmentary representation of data stored in the global 
resource locator in a registry and relation table, a portion of which as is communicated 



6 



with and stored in the local resource locator the latter which also holds a success history 
table; 

Fig. 7 is a flow chart showing programs of the subcontract bid managers in 
managing the data of the global resource locator and the local resource locator; 
5 Fig. 8 is a flow chart of the operation of the subcontract manager of Fig. 4 in 

updating the success history of Fig. 6; 

Fig. 9 is a tree structure showing a virtual cluster assembled by operation of the 
global resource locator and local resource locator providing for success weights from the 
success history table indicating methods of calculating likely success in bid 
10 subcontracting; 

Fig. 10 is a diagram representing the timing constraints on bidding in the present 
invention; and 

Fig. 1 1 is a representation of the data structures and functions collected in the 
global resource locator of Fig. 3. 

1 5 DETAILED DESCRIPTION OF THE INVENTION 

Referring now to Fig. 1, a distributed industrial control system 10 may include a 
plurality of machines 12, for example, manufacturing machines such as drills, lathes, 
ovens, mills and the like, each associated with an electronic computer 14 configured for 
electrical communication through I/O lines 30 with the machines 12. 

20 The electronic computers 1 4 may be linked to each other via a network 1 6 of a 

type well known in the art allowing for connected messaging or other commimication 
protocol between the various computers 14 whereby each of the computers 14 may 
produce messages for or consume messages fi-om other computers 14. A human machine 
interface HMI 20, being a conventional computer terminal or other similar device, may be 

25 attached to the network or one of the computers (as shown) allow for programming of the 
various computers 14 or data entry as will be described. 

Referring now to Fig. 2, each computer 14 includes a network interface 18 of 
conventional design for transmitting and receiving messages on the network 16 and 
communicating them to an internal bus 22. The internal bus 22 links the network 

30 interface 18 with computer memory 24, a processor 26 and I/O circuits 28, the latter 
which provide I/O lines 30 leading to sensors or actuators on the machines 12. A 
secondary communication port 32 may be available for connection to the human machine 
interface 20 as described above. The memory 24 may hold within it a conventional 
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multitasking operating system, for example, Windows NT (not shown) under which the 
various programs of the present invention may be simultaneously executed as tasks. 

Referring now to Fig. 3, as is generally understood in the art and as is described in 
the above referenced patents, under the operating system, in each computer 14, the 
5 present invention executes tasks that implement autonomous cooperative units (ACUs) 34 
configured for particular machines 12 with which the computer 14 and ACU 34 are 
associated. As part of its creation, each ACU 34 is programmed, for example, through 
HMI 20, with data representing the capabihties 48 of the machine 12 with which it is 
associated. This data indicates both the generic operation or operations performed by the 

10 machine 12 (termed: "services") and particular values quantitatively delineating that 
service (termed: "parameters"). For example, a rolling mill would have a service of 
"rolling material to reduced thickness" and might have parameters indicating maximum 
rolling speed, percentage reduction and the like. The particular capabihties 48 will be 
defined for specific machines 12 according to a standard job description language (JDL). 

15 Each ACU 34 also includes a set of goals indicating a local optimization that the 

ACU 34 will try to achieve within its parameters, and programs executing protocols for 
receiving the description of the job (written in JDL) that the ACUs 34 are called upon to 
complete. 

Upon receipt of the job description, each ACU 34 will parse the description, 
20 bidding on portions of it matching their capabilities 48 and forwarding other portions in a 
subcontracting process to other ACUs 34 along with requests for bid messages. 
Preferably, the ACUs 34 communicate with other ACUs 34 via an agent language such as 
KQML. ACUs 34 may successfiiUy bid on parts of the job reply with a bid success 
message upward to the bid requesters and in this way complete bids on the total job may 
25 be assembled at the uppermost ACU 34 in the bidding chain. Complete bids, meaning 
those having one ACU 34 successfully bidding on each part of the job, are compared to 
select a winning bid describing how the job will be allocated among the ACUs 34. 

Through this bidding process, the ACUs 34 mimic the actions of individuals 
within a market economy to divide up the parts of a job for execution by the various 
30 ACUs 34 without need for centrahzed coordination. When the machines 12 are 

reconfigured (e.g., configm-ed to different settings, added or removed), the new set of 
ACUs 34 may quickly reallocate their responsibilities using the same processes. 

Referring still to Fig. 3, the present invention adds to the prior art ACUs 34 
contained within the computers 14 three additional structures. 



The first additional structure is a subcontract bid manager (SCBM) 36. The 
SCBM 36, which will be described in greater detail below, generally manages requests 
for bids produced by the ACUs 34. In this way, the operation of the SCBM 36 in steering 
bids (as will be described) is invisible to the ACU's, simplifying their design. A given 
5 computer 14 may contain a number of ACUs 34 each associated with a SCBM 36. The 
SCBMs 36 may communicate directly with other ACUs 34 in the particular computer 14 
or another computer 14 and may also communicate with the local resource locator (LRL) 
38 also contained in the computers 14 which serves to direct them to likely ACUs 34 to 
receive requests for a bid. 
10 The second additional structure is this LRL 38 which is replicated only once for 

each computer 14 and which provides a cache-Uke storage area shared by the SCBMs 36 
and communicating with the SCBMs 36 on the high speed internal bus 22 as opposed to 
the slower network 16. Operation of the LRL 38 will also be described in greater detail 
below. 

15 The third additional structure is a global resource locator (GRL) 40. The GRL 40 

is generally implemented in a single of the computers 14 as indicated by the dotted lines 
however its influence extends among all of the computers 14. As will be described in 
more detail below, and referring also to Fig. 11, the GRL 40 provides a number of 
functions including serving as a central clearinghouse for information needed by the 

20 ACUs 34 in the bidding process per registry table 5 1 . This information may be 

selectively downloaded to the LRL 38, based on the operation of a capabiUty matcher 
108, to create communication clusters which serves to reduce communications over 
network 16. The GRL 40 also modifies these clusters according to learning protocols 
104, and applies coordination rules (such as implements bid expiration timers) per context 

25 coordination protocols 102. The GRL 40 is also an ACU 34 and generally handles inter 
ACU communication per communication protocols 106. 

The following processes are implemented by data and programs implemented in 
these additional structures with little additional programming of the ACU's 34. Although 
particular functions will be ascribed to particular ones of these structures of the GRL 40 

30 the LRL 38 and the SCBM 36, it will be understood to one of ordinary skill in the art that 
the function responsibilities can in some cases be moved from one element to another and 
that the invention should not be considered to be limited to this fmictional division except 
insofar as it is essential to the purposes described herein. 
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Referring now to Fig. 4, in an example control system 10 having multiple 
computers 14a- 14c, the GRL 40 may be implemented in the first computer 14a to serve in 
shared capacity with each of computers 14a through 14c. Conversely, each computer 14a 
to 14c has a separate LRL 38a through 38c and separate ACUs 34a and 34a' (in computer 
5 14a) ACU 34b (in computer 14b) and ACU 34c (in computer 14b). Each ACU 34a, 34a', 
34b and 34c are associated with corresponding SCBMs 36a-36c. 

Referring now to Figs. 1, 4 and 5, in initializing the control system 10, the ACUs 
34a through 34c are created, for example, through commands and data entered into the 
HMI 20, according to a prewritten ACU template and the entering of data configuring 
10 each ACU's particular services, parameters and goals as indicated by process block 41 . 

As indicated by subsequent process block 42, at the time of this initiahzation, each 
ACU 34 sends a registration message to the LRL 38 of its computer 14. The message 
describes the capabihties of the ACU 34 including both its services and parameters. The 
LRL 38 uses this information to create a row entry 44 in local directory 43 as indicated in 
15 Fig. 6. The row entry 44 includes an identification 46 of the ACU 34 in a first column 
and capabihties 48 of the ACU 34 in a third and fourth column. The identification 46 
may simply be the physical address of the ACU 34 on the network allowing ready 
communication with the particular ACU 34. The second column is reserved for listing 
related ACUs 34 as will be described and these ACUs 34 may also be identified by their 
20 physical address on the network 16. 

The LRL 38 acknowledges this message and the ACU 34 waits for an incoming 
job description language message to begin the bidding process as described above. 

Next, as indicated by process block 50, the LRL 38 registers the information 
provided by the ACU 34 with the GRL 40. Because the LRL 38a in this example is 
25 shared with two ACUs34a and 34a' in computer 14a for this LRL 38a, there will be a 

second row entry 44' for the second ACU 34. In this example, the ACU 34a is associated 
with an oven and has as its service, heating and parameters X;, Yi, X3. 

In the registration process of process block 50, the LRL 38 sends to the GRL 40 
the identification 46 and the capabilities 48 of each row entry 44 and 44'. As noted 
30 before, service information indicates generally the type of operation in the manufacturing 
environment performed by the machine 12 associated with the ACU 34. 

The GRL 40 places this material in a registry table 5 1 as row entries 45. At this 
time the GRL 40 may create a relation table 54 indicating each registered ACU 34 by its 
identification 46 and in a second column indicating dependent services 56 likely to be 
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used in conjunction with the capabilities 48 of the particular ACU 34. These dependent 
services 56 provide an initial means to identify other ACUs 34 that are promising targets 
for requests for bids. For example, if ACU 34a (having an identification 46 of 1) is a 
heater, it may logically be followed by a rolling mill as indicated in the relation table 54. 
5 Thus, for example, in a job requiring heating, then rolling and cooHng of metal strips, 
ACU 34a would bid on the heating and then need to request bids on the rolhng. 

Specifically, the relation table 54 may be created by applying known relationships 
between services (e.g. heating and rolling) and matching the services of the ACUs 34 
from the registry to the appropriate corresponding dependent service 56 per the relation 

10 table 54. Alternatively, at the time of creation of the ACUs 34 per process block 41, 
dependent services 56 can be identified. The relation table 54 may hold multiple 
dependent services 56 for each ACU 34. 

Alternative or in addition, the relation table 54 may indicate physical connections 
between machines 12 such as may further limit relations between ACUs 34 insofar as the 

15 machines 12 may need a direct path of communications. In this regard, the dependent 
services 56 may simply identify specific other ACUs 34 by identification numbers, for 
example, those having a material transfer path connecting to ACUs in sequential fashion. 
As will be seen, the initial loading of the relation table may be modified as the process 
continues and thus is not critical in accuracy. 

20 Referring again to Fig. 5, as shown by process block 58, upon receiving the 

registrations from a given ACU 34, the GRL 40 consults the relation table 54 and 
multicasts the identity of the given ACU 34 and its capabilities to the LRLs 38 associated 
with other ACUs 34 that Hst dependent services 56 in the relation table 54 matching the 
capability 48 of the given ACU 34 recorded with the registry table 5 1 . This is under the 

25 control of the capabiUty matching protocol 108 shown in Fig. 1 1 . These transmissions 
may be updated as new ACUs 34 are registered. Generally the LRLs 38 have less storage 
capacity than the registry and hence the GRL 40 limits the multicast to data on a "cluster" 
of ACUs 34, the identity of which is stored in a cluster record 86 being part of the 
registry. Initially the cluster may be randomly chosen. The multicasting and other inter- 

30 ACU communications tasks are handled by the GRL 40 using agent communication 
protocols known in the art and as indicated by block 106 of Fig. 1 1 . 

The LRLs 38 receiving this multicast, enter the transmitted data under the 
appropriate row entries 44 of the ACUs 34. Thus for example, as shown in Fig. 6, when 
ACU number 3 having a capability 48 including "rolling" is entered into the registry table 
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51, the GRL 40 scans the relation table 54 and determines that the ACU number 1 may 
logically send requests to bid to this ACU number 3. The data for ACU number 3 (a 
potential bid request receiver) is then enrolled in the LRL 38 responsible for ACU 
number 1 beneath the row entry 44 for ACU number 1. In this way, an individual ACU 
5 34 may consuh with the LRL 38 to find likely candidates for receiving bid requests 
without network traffic. 

At the same time that the potential bid request receivers are enrolled in the LRL 
38, they are enrolled in success history table 72 also held in the LRL 38. A first column 
of the success history table 72 holds the identification 46 of an ACU 34 associated with 

10 the LRL 38 and a second column holds the identification 46' of the potential bid request 
receiver downloaded to the LRL 38. A third column shows a priority values 78 indicating 
hkely success in bids between these ACU's based on historical data to be collected. 
Initially this priority value is set to one however it will vary over time as more historical 
data is collected as to how likely it is that the indicated ACU will return a successful bid. 

1 5 At the conclusion of this registration process, each of the ACUs 34a through 34c 

is registered with the GRL 40 and the associated LRLs 38a through 38c contain a list of 
potential bid recipients for their ACUs 34. 

Referring now to Fig. 7, the value of the LRL 38 and the GRL 40 is illustrated as a 
given ACU 34 receives a bid request associated with a job description or portion of the 

20 job description (in JDL) as indicated by process block 64. According to standard 

operation of the ACU 34, the ACU 34 examines the job description to see if it has parts 
that match the capabilities of the equipment 12 associated with the ACU 34 as indicated 
by decision block 66. If the ACU cannot perform a part of the job, the bid is rejected and 
communicated to the requestor as indicated by arrow 67. On the other hand, if the ACU 

25 34 can perform a part of the job, the ACU 34 consults with its LRL 38 via the SCBM 36 
as indicated by decision block 68 to see whether they are potential candidates for sub 
bidding. 

At process block 64, it should be noted that multiple ACUs may send bid requests 
to a particular ACU 34 and each is provided with a separate context. Multiple contexts 
30 allow a given ACU to act as if the requests for bids were received by separate ACUs with 
the same address. Referring again to Fig. 6, this process involves reviewing the rows of 
the LRL 38 beneath the inquiring ACU's row entry 44 to see if there are other ACUs 34 
enrolled with the necessary capabilities required by parts of the job description not being 
performed by the inquiring ACU 34. If no potential bid requesters having suitable 
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capabilities are listed in the LRL 38, the process continues at process block 70 as will be 
described below. 

On the other hand, if potential bid requesters are listed in the LRL 38, then the 
success history table 72 is consulted to determine whether these candidates have 
5 historically provided successful bid responses. The identification 46 of the particular 

ACU 34 seeking to make a bid request is located in the first column of the success history 
table 72 and the identification 46 of the potential bid request receiver is located in a 
second column together to define a row which includes a priority value 78. This priority 
is compared against a predetermined threshold, for example, 0.5 and if it is greater than 

10 that, a bid request receiver is considered successfiiUy found and a request for bid will be 
forwarded to this identified ACU per process block 94 as will be described below. If 
however, none of the candidates subcontracting ACUs have sufficiently high priority, the 
program proceeds again to process block 70. Repeated failure to find successful bid 
recipients in the success history table 72 may be used to modify the threshold against 

15 which priorities are compared. 

Failure to find a suitable bid recipient in the LRL 38 is not conclusive, because 
LRLs 38 tend to be limited by the small size of the computers 14 and far greater 
information is contained in the registry table 51 of the GRL 40. Accordingly, if no 
suitable bid request receiving ACU is found, the SCBM 36 communicates with the GRL 

20 40 to obtain a new cluster of related ACUs 34. The GRL 40 may respond in two ways 
according to the learning protocol 104 (shown in Fig. 11). If the needed bid recipient 
ACU is of dependent services 56 not Msted in the relation table 54 for the requesting ACU 
34, the GRL 40 will update the relation table 54 by adding the new dependent service 56 
and using this new dependent service 56 will rescan through the registry table 5 1 to 

25 obtain a new cluster of ACUs. 

Ahematively, it may be the case that process block 70 is reached when bid request 
receiving ACUs with the proper dependent capability were found in the LRL 38 but their 
priority values 78 in the success history table are too low. In this case, the GRL 40 will 
select a new set of ACUs from the registry table 51 different fi-om those listed in the 

30 record 86. 

Tracking of previously provided ACUs may be held in the record 86 so that 
rejected ACUs will not be resubmitted to the LRL 38 until all others have been exhausted. 
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As the new cluster of ACUs is enrolled in the LRL 38, the success history table 72 
is also updated and priority values for these new ACU's are set to one. This indicated by 
process block 88. The program then proceeds to process block 68 as described above. 

Referring still to Fig. 7, if an ACU within the cluster and suitable for receiving a 
5 bid is identified at process block 68, then at process block 80, a bid request is submitted 
to this ACU 34. The resuhs of this bid request are then reported back as indicated by 
arrow 67. In order to simplify and reduce network transmissions, this transmission 
reporting back follows the following rules: 

At process block 96, if the reply to a bid request (for each context) contain any 
1 0 successes indicating not only that the ACU to which a request for bid was submitted 
responded favorably, but that it found ail necessary subcontracting ACUs to respond 
favorably, then only successes and the data from those ACUs on responding to the bid are 
forwarded to the proceeding ACU. If there are multiple successes from different 
contexts, each success is forwarded. The reporting of counter bids and failures are thus 
1 5 truncated preserving network bandwidth. 

If there are no successes, then if any of the bid responses are coimter bids, only the 
counter bids are forwarded. If there are multiple counter bids from different contexts, 
each counter bid is forwarded. 

If there are no successes or counter bids, then only failures are forwarded together 
20 with reports as to why the failures occurred. 

Referring now to Fig. 8, one ACU 34 associated with a product rather than a piece 
of equipment, may be nominated to submit the original job description with all its parts as 
indicated by process block 97. This ACU 34 may then receive the bid responses 
described above as indicated by process block 98. As shown by process block 100 
25 messages indicating successful bids are then multicast to all LRLs 38 of ACUs 34 

contributing to the bids. This information is used to modify the success history of the 
particular LRL in relationship to the corresponding co -contracting ACU. In particular, 
this involves moving the priorities up for those combinations of ACUs 34 being part of a 
successful bid (unless they are already at a value of one) and moving priorities down if 
30 the particular combination of ACUs 34 was not part of a successful bid. In this way the 
priorities change over time in a learning process. 

Referring now to Fig. 9, it can be seen that for a given ACU A, over time the 
success history table 72 will assign priority values 78 to its relationship with 
subconfracting ACUs A B and C. Likewise priorities will be assigned at the LRLs of 
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ACUs B and C for their relationships with ACU's D and E and F and G, respectively. By 
following the path of highest priorities (implicit in the process described above), quicker 
conclusions of a bid will be obtained (with fewer bid messages) so long as the bid 
successes are consistent on a historical basis. 
5 Because of the extremely large solution space and large number of possible chains 

through ACUs in the bidding process, it is desirable to limit the amount of time before 
which a response to a request for bid must be received. This prevents lost messages from 
stalling the process and truncates extremely long searches through possible solution 
space. 

10 Referring now to Fig. 10, accordingly each request for bid is attached to a 

response time value 92. This is done by the global resource locator 40 as it handles 
communications of messages related to different contexts per the context coordination 
protocols 102 shown in Fig. 1 1 . As noted above, a request for bid will include the portion 
of the description that could not be implemented by the current ACU and thus requires 

15 further requests for bid from other ACUs. This response time value 92 is propagated in 
modified form in all subsequent request for bids by those ACUs 34 receiving the initial 
request for bid. The modification subtracts from the response time value 92 at each level 
in the bidding process, time necessary for processing the initial request for bid. So for 
example, and ACU A may transmit a request for bid 91 having a response time value 92 

20 of 1 .0 to ACU B . ACU B in turn may make other requests for bids 9 1 ' having attached 
response time values 92 of 0.7, allowing 0.3 of processing time for ACU B to respond. 
This chain is continued with each subsequent ACU 34 requesting a response time value 
that is less than the time allotted to it from the previous ACU 34 so that prompt response 
may be guaranteed. The response time values 92 of Fig. 10 are preserved independently 

25 for each context of the ACU. 

In this way, it can be assxired that ACU B receives its bid responses in sufficient 
time to forward them to ACU A in the time it requires. Bids received after the response 
time value 92 are treated as failures. 

It is specifically intended that the present invention not be limited to the 

30 embodiments and illustrations contained herein, but modified forms of those 

embodiments including portions of the embodiments and combinations of elements of 
different embodiments as come within the scope of the following claims. 



15 



WE CLAIM: 



CLAIMS 



1 . A method of coordinating a plurality of autonomous cooperative units (ACUs) 
implemented in computers intercommunicating on an electronic network and operating to 
divide a predefined job among ACUs by a bidding process in which bid requests are 
communicated on the electronic network among the ACUs, the method comprising the steps 
of: 

(a) for each ACU identifying potential bid request receivers being a subset of all 
ACUs of the plurality; 

(b) storing a list of potential bid request receivers in the computer implementing the 

ACU; 

(c) receiving a description of a job at a given ACU; 

(d) preferentially communicating requests forbids related to the description of the job 
from the given ACU only with other ACUs of the list of potential bid request receivers; 

whereby communication traffic on the network may be reduced. 

2. The method of claim 1 wherein each ACU is associated with at least one capability 
describing operations of the process controlled by the ACU and wherein step (a) identifies 
potential bid request receivers based on the capability of a given ACU and a relation table 
relating capabilities of a bidding ACU to capabilities of a potential bid receiver. 

3. The method of claim 1 wherein each ACU is associated with capabilities 
describing operations of the process controlled by the ACU and related to completion of a 
portion of the job and further including the steps of: 

(e) storing at a designated computer a relation table relating ACUs to capabilities of 
potential bid request receivers for those ACUs; 

(f) collecting from each ACU at a designated computer on the network, the 
capabilities of each ACU; and 

(g) transmitting from the designated computer on the network to computers 
implementing a given ACU, potential bid request receivers for the given ACUs based 
capabilities of other ACUs matching the relation table entry for the given ACU. 
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4. The method of claim 3 wherein each ACU transmits its capabiHties to the 
designated computer upon initiaUzation of the ACU. 

5. The method of claim 3 wherein the designated computer also implements at least 
one of the ACUs. 

6. The method of claim 3 wherein the designated computer stores the capabilities of 
each ACU in a central registry and wherein the list of potential bid request receivers 
transmitted to the given ACU defines a cluster of ACUs smaller than the number of potential 
bid request receivers held in the central registry. 

7. The method of claim 6 wherein the list of potential bid request receivers includes 
information indicating the likelihood of an ACU on that list being able to complete a portion 
of a job, and wherein step (d) of preferentially communicating requests for bids fi-om the 
given ACU to other ACUs on the list of potential bid request receivers includes the steps of: 

5 (i) reviewing at the given ACU the list of potential bid request receivers for ACUs 

likely to complete a portion of the job; 

(ii) when there are no likely ACUs, communicating with the designated computer for 
a new cluster of ACUs to update the list of potential bid request receivers; 

(iii) preferentially communicating requests forbids related to the description of the 
10 job from the given ACU only with other ACUs of the updated Hst of potential bid request 

receivers. 

8. The method of claim 7 wherein the designated computer responds to the 
communications of step (ii) by providing a new cluster of potential bid request receivers 
according to the criterion of the ACUs of the new cluster being different from the ACUs of 
the cluster it replaces. 

9. The method of claim 8 wherein at step (ii) the given ACU also communicates to the 
designated computer that the list of potential bid request receivers does not include an ACU 
with a desired capability and wherein the designated computer provides a new cluster by 
changing the relation table relating ACUs to capabilities of potential bid request receivers for 

5 those ACUs by adding a new capability of potential bid request receivers of the given ACU. 
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10. The method of claim 9 wherein the ACU stores historical data tracking the 
likelihood of another ACU accepting a bid request and wherein at step (ii) the given ACU 
also communicates to the designated computer that hst of potential bid request receivers does 
not include an ACU with a likelihood of accepting a bid request and wherein the designated 

5 computer responds by providing a new cluster by using the relation table to identify new 
potential bid request receivers for the given ACUs based on capabilities of other ACUs 
matching the relation table entry for the given ACU. 

11. In an industrial controller including a plurality of autonomous cooperative units 
(ACUs) implemented in computers intercommunicating on an electronic network and 
operating generally according to a stored program to divide a predefined job among ACUs by 
a bidding process including bids communicated on the electronic network among the ACUs, 

5 the improvement comprising additional stored program executed by the ACUs to: 

(a) identify potential bid request receivers for each ACU being a subset of all ACUs 
of the plurality; 

(b) at each ACU storing a list of potential bid request receivers in the computer 
implementing the ACU; 

1 0 (c) receiving at a given ACU a description of a job; 

(d) cause the given ACU to preferentially communicate requests for bids related to the 
description of the job from the given ACU only with other ACUs of the list of potential bid 
request receivers; 

whereby communication traffic on the network is reduced. 

12. The industrial controller of claim 1 1 wherein each ACU is associated with 
capabilities related to completion of a portion of the job and wherein the ACUs further 
execute the program steps of: 

(e) storing at a designated computer a relation table relating ACUs to capabilities of 
5 potential bid request receivers for those ACUs; 

(f) collecting fi-om each ACU at a designated computer on the network the capabihties 
of each ACU; and 

(g) transmitting from the designated computer on the network to computers 
implementing a given ACU, potential bid request receivers for the given ACUs based 

1 0 capabilities of other ACUs matching the relation table entry for the given ACU. 
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13. The industrial controller of claim 12 wherein the ACUs further execute the 
program so that each ACU transmits its capabilities to the designated, computer upon 
initialization of the ACU. 

14. The industrial controller of claim 12 wherein the designated computer also 
implements at least one of the ACUs. 

15. The industrial controller of claim 12 wherein the designated computer further 
executes program steps to store the capabilities of each ACU in a central registry and wherein 
the list of potential bid request receivers transmitted to the given ACU defines a cluster 
smaller than the number of potential bid request receivers held in the central registry. 

16. The industrial controller of claim 15 wherein the list of potential bid request 
receivers includes capabihties of the hsted ACU to completion of a portion of a job, and 
wherein program step (d) of preferentially communicating requests for bids from the given 
ACU to other ACUs on the list of potential bid request receivers includes the program steps 

5 of: 

(i) reviewing at the given ACU the list of potential bid request receivers for ACUs 
having capabilities matching the received description of the job; 

(ii) when there are no matching ACUs, communicating with the designated computer 
for a new cluster of ACUs having capabilities matching the relation table entry for the given 

1 0 ACU to update the list of potential bid request receivers; 

(iii) preferentially communicating requests for bids related to the description of the 
job from the given ACU only with other ACUs of the updated list of potential bid request 
receivers. 
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17. The industrial controller of claim 16 wherein the designated computer responds to 
the communications of step (ii) by providing a new cluster of potential bid request receivers. 

18. The industrial controller of claim 17 wherein at step (ii) the given ACU also 
communicates with the designated computer that the list of potential bid request receivers 
does not include an ACU with a desired capabiUty and wherein in response the designated 
computer provides a new cluster by changing the relation table relating ACUs to capabilities 

5 of potential bid request receivers for those ACUs by adding a new capability of potential bid 
request receivers of the given ACU. 

19. The industrial controller of claim 1 8 wherein the ACU stores historical data 
tracking the likehhood of another ACU accepting a bid request and wherein at step (ii) the 
given ACU communicates to the designated computer that list of potential bid request 
receivers does not include an ACU with a Hkelihood of accepting a bid request and wherein 

5 the designated computer responds by providing a new cluster by using the relation table to 
identify new potential bid request receivers for the given ACUs based capabilities of other 
ACUs matching the relation table entry for the given ACU. 

20. The industrial controller of claim 1 1 wherein each ACU is associated with at least 
one capability describing operations of the process controlled by the ACU and wherein 
program step (a) identifies potential bid request receivers based on the capabihty of a given 
ACU and a list relating capabilities of a bidding ACU to capabilities of a potential bid 

5 receiver. 
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ABSTRACT 

A distributed control system employs a number of autonomous cooperative units that 
intercommunicate with bids and counter bids to allocate the production of a product among 
them. Network traffic caused by these bid messages is significantly reduced by creating as a 
central clearinghouse, a global resource locator that can identify autonomous cooperative 
units more hkely to be receptive to bids from other autonomous cooperative units. Portions 
of the data of the global resource locator are held at the particular computers implementing 
the autonomous cooperative units in a cache-like structure that may be referred to without 
network communication. Misses within this cache structure cause a refreshing of the cache 
from the global resource locator and an updating of a learning relation table that further 
improves predictions in the ftiture. Historical successes in bidding are stored at the cache 
structure to further aid in selecting likely bid recipients. 
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